The Conduit X4 and X1 are unique data boxes for virtual production and VFX purposes. On this page, we'll go over how they work and how they can best be utilized on your production!
For decades, camera accessory hubs have come in the form of "boxes." We have timecode boxes, follow focus receiver boxes, cinetapes, and more. A key aspect of these is they are designed to operate totally standalone. This makes sense, as traditional production requires portability of all aspects of the camera. Unfortunately, this also comes with a number of limitations. First, the data processing that these devices do is bottlenecked by the power of whatever embedded processor is inside the device. This will generally be a low power processor--no more than a few hundred MHz--which puts a hard limit on the amount and speed of data that can be processed. For virtual production, this directly affects the overall latency of the device. Second, these devices are locked into the functionality that they are programmed for. This might seem obvious, but most of the physical communication interfaces used on film equipment are common--RS232, CAN, Ethernet, etc.--and the only differences are the specifics of the protocols themselves, and how the data is decoded after it is read.
The Conduit system takes a different approach. The key realization was that in virtual production, we only need one data "box"--a PC. If we could simply get data to and from the PC efficiently, than the processing could entirely be done with the full power of the desktop processor, resulting in lower latency overall. Additionally, as long as the Conduit knows what specifically defines a complete data packet (end of frame character, length specifier, etc.) than new protocols could be added on the fly by the host software. This is the approach taken by the Conduit system.
The Conduit X4 also provides an expansion interface on the back for future addon modules.
When plugged in, the Conduit will attempt to acquire an IP address through DHCP. If the network does not provide DHCP, or you want to use a static address, you will be able to configure these settings manually through USB in LONET Server 2. Once an IP is acquired, the menu will be displayed.
Since the Conduit does not do any onboard data processing, protocols are specified through Protocol Definition packets from host software running on the network. The available protocols will be selectable based on what the software can decode. At launch, the following protocols will be available:
Protocol | Software |
---|---|
Glassmark II | LONET Server |
Cooke /i | Reality Field Base |
Zeiss XD | Reality Field Base |
Preston | Reality Field Base |
Information about how to do this will be made available to developers.
When a timecode source is provided to Reality Field, it can share that timecode data over the network to devices listening to the LONET 2 protocol. Conduit boxes are configured to poll their serial ports when this timing information is received. If a timing packet is not received for 50 milliseconds, it will revert back to free run mode. In free run mode, the Conduit will poll the device and send it's data as fast as possible. The exact speed of this will vary depending on the amount of data transferred. For a Glassmark 2 encoder, this could be several thousand hertz. For an XD data lens, this might only be 48 hertz.
The timecode is attached to the packet and maintained through the data flow. It can be used by systems like Unreal to ensure that the data is accurate and recent.
At present, Reality Field supports timecode through Decklink cards video input. Support for Aja cards is on the roadmap, which will add dedicated LTC and Genlock functionality.